The present invention relates generally to upgrading software on a continuously operating computer system, and, more specifically, to effecting such upgrades in the field of telecommunications systems.
Computer programs which are initially installed and configured on one or more storage devices in the system at start up typically control continuously operating computer systems. The programs are sets of software instructions which perform together to control a variety of functions in many different components of the system.
It is often desirable to make modifications to such system software in order to provide additional features to the system, to solve problems or xe2x80x9cbugsxe2x80x9d which have been found during operation of the system, or to accommodate new developments in technology. Conventionally, when a software upgrade is to be made, a new version of the software code is typically installed and configured on the system. For example, the new code is often installed as a traditional download but for this, normal operation of the running system must be interrupted. Shutting down system operations, in whole or in part, leads to financial and service losses due to the downtime involved.
A mechanism of upgrading stand alone programs, such as word-processing programs or drafting programs, was described in U.S. Pat. No. 5,764,992 (Kullick). In accordance with the method described in Kullick, the program checks for an updated or more recent version of itself upon start up. The new version may be resident in the memory on the hard disk or on a network file server. When the current version starts up and finds that an updated version exists, it overwrites itself with the updated version. The entire program thus replaces itself with a new version during start up, or shut down. Alternatively, the new program can be written to install itself while the computer is not in use. The Kullick patent describes a method of replacing an entire program with a new version of itself while the system is essentially down or not in use.
In a continuously running system, however, such as a telecommunications system, there is no time at which the system is routinely down or not being used. More specifically, a telecommunications system operates continuously as consumers expect to have access to telephone service twenty-four hours a day. Thus, interruptions to system operation can be extremely costly for the service provider and, at the very least, inconvenient to users.
A telecommunications switching system can be comprised of several switching nodes and voice processing resource nodes which are inter-connected by an inter-nodal network, often connected as a ring. Such a system is controlled by software tasks resident on a host computer or a network file server, as well as in microprocessors running on individual cards, like a switching matrix card or a line card and the like. These cards are located within a switching node, voice processing resource node or other application service node. It is often necessary or desirable to upgrade software running on these microprocessors in order to provide additional features, to solve problems which have arisen during the operation of the system or to bring a new card into service. This does not always involve the entire system, but rather, for example, may relate to the software resident on a particular node, or on a portion of software which is running on one type of line card in the system. In addition, many times, a xe2x80x9cpatchxe2x80x9d of a portion of code is to be made by replacing or modifying a portion of the program. In such a case, it is unnecessary to replace all of the software running on a particular type of card, instead it may be that merely a few lines of code are to be replaced.
At present, software upgrades to telecommunications systems and other continuously running systems have been managed as system software releases which are installed as traditional downloads for which system operation must be interrupted, even if only a portion of the system is affected by the upgrade.
A method of replacing an entire program, or a task, running on a telecommunications system has been described. However, this involves a complex mechanism for replacement of substantially the entire task and may also require shut down of certain aspects of the system, or even the entire system.
There remains a need, therefore, for a mechanism by which a software upgrade may be effected in a continuously running system, without interruption of operation of the system.
There remains a further need for the ability to amend only a portion of a running software program in such a system or in a subset of the system.
The present invention is a method and apparatus for performing a live upgrade of the software running on a continuously operating system, such as for example, a telecommunications system, without interrupting the operation of the system.
Briefly, in accordance with the invention, a software upgrade mechanism includes a unique method of building a base set of software that includes the capability of accepting an upgrade which can then be activated while the system is on-line. The method of the present invention includes establishing in the base software architecture, a reserved memory area. The reserved memory area is an allotment of a portion of memory that is held available for prospective upgrades; and it represents a corresponding reserved memory area in each memory storage device in each component in the system for which the upgrade is targeted.
In accordance with the invention, when an upgrade is to be built, the first step in the process is to write upgrade source files and place them within the file set of an existing base build. It is assumed that a base build has previously been written. Next, the up-grade source files are written. The upgrade source files contain various products, such as, for example: code, uninitialized data, initialized data, constants and the like. Each product of a particular type associated with that upgrade is given a predetermined name in accordance with a suitable naming convention.
The base files and the upgrade source files, as well as build instructions are inputs to an appropriate make/build software utility. The build instructions notify an associated compiler and linker where to locate in memory the various portions of the build depending upon the names of those products. The products of the upgrade source files having particular names are located at designated addresses in the reserved memory area. In addition, the compiler and linker resolves the addresses to all referenced global data or other functions in the base software build to ensure that code in the upgrade that calls routines in the base build can identify where those routines are located.
As will be well understood by those skilled in the art, after compiling and linking, a map file is produced. The map file includes information such as the names of the products of the base build and of the upgrade build. It also includes information about where those products are located in memory which ultimately leads to the determination as to where those products will be located in the individual memory storage devices in the system after the download.
In accordance with the invention, a software utility reads the map file and identifies where in the memory image of the overall build the upgrade is located. The utility then extracts the upgrade products and generates a loadable upgrade image which consists of the upgrade (without the base build) and a header.
The header is designed based upon the information in the map file and is associated with the loadable upgrade image. The header may include information about the type of system component, such as a matrix card or a line card in a telecommunications system, for which that particular upgrade is targeted, the address in the reserved memory area of the storage device in that card at which the upgrade is to be stored, as well as other information such as checksum information, date, and the relevant software revision number.
The upgrade is then downloaded to the targeted cards in the system. Such downloads can be performed while the system software is running, and without interruption of the operation of the system, as the reserved memory area does not yet contain live code. The upgrade code that is downloaded into the reserved memory area is later activated in accordance with the invention. The downloads can thus be performed without overwriting existing code, and without the need to replace the entire program.
After downloading is complete, the upgrade may be activated. All upgrades do not have to be activated at the same time, or at all. It may be that although all line cards of a particular type receive an upgrade, it is desired to activate the upgrades in only certain of the nodes in the system. In accordance with the invention, the user can determine which upgrades are to be activated.
Activation is performed by overlaying an instruction which transfers control to a different address using a hard jump sequence, for example. In accordance with one aspect of the invention, a load-address-and-jump instruction sequence is overlaid at the beginning of an old function, which directs the program to the beginning of a new function, which has been loaded, into the reserved memory area for the upgrade. In an alternative embodiment of the invention, where an address table is being utilized to dynamically call up routines, then the new addresses of the upgraded code are loaded into available spaces in the jump table which direct the CPU to those new addresses. In either case, the context of the old routine is maintained and the CPU returns to where it would have returned had the old routine been executed. A simple mechanism is used to determine the integrity of activation of upgrades so that a piece of code that is executing at that moment is not patched while executing, as discussed in detail herein.
A messaging sequence between the host and a processing card in the system includes a means of querying the status of downloaded upgrades to determine whether that upgrade is activated or deactivated, as well as to compare the upgrades a card actually contains against a host-controlled list of upgrades that such a card type should contain. The query message may also include information about the amount of memory space available in the reserved memory segments for additional upgrades, if desired.